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(54) Access control for computers 

(57) The invention provides a general and flexible 
mechanism for a secure access control on a computer. 
Cryptographic checksums are applied for the identifica- 
tion of a program to another program. These crypto- 
graphic checksums are generated automatically for the 



programs. Each program has its program-specific iden- 
tifier which can be regarded as a substantially unique 
value or name. Such a program-specific identifier can 
be used to verify the validity of one program to another 
program. Mutual trust relationships between different 
programs can therewith be set up easily. 
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Description 
TECHNICAL FIELD 

[0001] The present invention relates to secure and 
trusted processing of programs and applications on a 
computer. More particularly, the invention is related to a 
mechanism for the identification of a program to another 
program. 

BACKGROUND OF THE INVENTION 

[0002] Traditional computer and computer systems, 
particularly connected systems within a defined net- 
work, are managed by systems administrators. The cur- 
rently used access control mechanisms have focused 
on separating the users from one another based upon 
a security policy determined by the systems administra- 
tors. Some, primarily military, systems have allowed fin- 
er-grained access control poBcies allowing separation 
of different aspects of an individual user but the com- 
plexity of these systems made them prohibitively expen- 
sive to administer. As a result, these system access con- 
trol mechanisms have not been widely adopted. 
[0003] The access control schemes available in vari- 
ous databases and in Java offer finer-grained control of 
data and objects but do now solve the general problem 
of access control at the system level. 
[0004] Most personal computers (PC) can not solve 
sufficiently the problem of security. PC operating sys- 
tems, including DOS, Windows, and MacOS, have been 
assaulted by a barrage of viruses, Trojan horses, and 
other malicious software, also referred to as malware. 
The release and use of such malware has been essen- 
tially a form of vandalism and its danger grows with the 
use of the Internet. 

[0005] If one use such systems for economically 
meaningful transactions, there is far greater benefit and 
hence incentive for an attacker. Thus, the need for se- 
curity is essential whereby a call arises for an appropri- 
ate access control mechanism. 
[0006] The form factor and usage characteristics of 
hand held devises, such as personal digital assistants, 
also abbreviated as PDAs, makes them extremely de- 
sirable for use in many e-commerce applications. Un- 
fortunately, current PDA operating systems do not offer 
the needed security for e-commerce applications. The 
very fact that PDAs are powerful and general purpose 
computing devices renders them vulnerable to attack. 
E-commerce systems based upon PDAs are potentially 
vulnerable to an entire range of attacks which also can 
endanger other included systems, e.g. smarfcards. 
[0007] Commonly, a system administrator must deter- 
mine how much trust can be given to a particular pro- 
gram and/or user. This determination includes consid- 
ering the value of the information resources on the sys- 
tem in deciding how much trust is required for a program 
to be installed with privilege. It is a drawback that the 



system administrator has to update the system and the 
privileges continuously. 

[0008] US Patent No. 3,996,449 is related to an oper- 
ating system authenticator for determining if an operat- 

5 ing system being loaded in a computer is valid. A user's 
identification code or secret key which is unique to the 
operating system, and a verifier value which is a prede- 
termined function of a valid operating system and the 
identification code are respectively stored. A hash func- 

10 tion, which is a function of the operating system being 
loaded and the identification code, is generated by the 
authenticator. After the operating system is loaded, the 
hash function is used as an authenticating value and 
compared with the verifier value for determining the au- 

*5 thenticity of the loaded operating system. 

[0009] In US Patent No. 5, 1 1 3,442 a method, and an 
operating system utilizing this method, for controlling ac- 
cess rights among a plurality of users is described. Each 
user is provided a user identification number which is 

20 prime and each secure object is provided an access 
code which comprises a value that Is a product of the 
user identification numbers of all users having the same 
access rights to that secure object. In response to a re- 
quest by a userfor access to asecure object, the access 

25 code for that secure object is divided by the user iden- 
tification number of the requesting user. 
[0010] Access rights of the user to the requested se- 
cure object are determined based on whether the result 
of the division yields a zero remainder. 

30 

GLOSSARY 

[001 1] The following are informal definitions to aid in 
the understanding of the following description. 

35 [0012] Hash function is a computationally efficient 
function mapping binary strings of arbitrary length to bi- 
nary strings of some fixed length. 
[0013] One-way hash function is a function which 
takes a variable-length message M or some data and 

40 produces a fixed-length value, also referred to as hash 
or specific identifier. Given the specific identifier, it is 
computationally infeasible to find a message with that 
specific identifier; in fact one can't determine any usable 
inf ormation about the message M with that specific iden- 

45 tifier. In other words, the time to create such a specific 
Identifier Is substantially shorter than the time to recon- 
struct the variable-length message out of the specific 
identifier. Moreover, the time to find two identical specific 
identifiers is substantially longer than the time to create 

50 one specific identifier. 

[0014] Trusted computing base (TCB) indicates the 
totality of protection mechanisms within a computer sys- 
tem, including hardware, firmware, and software, the 
combination of which is responsible for enforcing a se- 

55 curity policy. 
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OBJECT OF THE INVENTION 

[0015] It is an object of the present invention to over- 
come the disadvantages of the prior art. 
[0016] It is another object of the present invention to 
provide a mechanism for a secure access control of pro- 
grams on a computer or on distributed systems. 
[0017] It is still another object of the present invention 
to provide an access control mechanism which not re- 
quires any system administrator. 
[001 8] It is a further object of the present invention to 
present an access control mechanism which is unspoo- 
fable and therefore works in a secure manner. 
[001 9] It is yet another object of the present invention 
to provide a method and an apparatus for verifying the 
identity of a program on a computer to another program 
on the same or different computer. 

SUMMARY AND ADVANTAGES OF THE INVENTION 

[0020] The objects of the invention are achieved by 
the features stated in the enclosed independent claims. 
Further advantageous implementations and embodi- 
ments of the invention are set forth in the respective sub- 
claims. 

[0021] The invention provides a general and flexible 
mechanism for a secure access control on a computer 
or on distributed computers. When referring to a com- 
puter, any kind of computer is meant that has a trusted 
computing base, also abbreviated asTCB. Such a com- 
puter can be a member of a network and can support 
multiple secure domains or applications. 
[0022] The basic Idea of the invention is that a com- 
puter uses cryptographic functions, i.e. cryptographic 
checksums, also referred to as one-way-hash functions, 
to automatically generate program-specific crypto- 
graphic identifiers or short program-specific identifiers 
and form therewith the basis of an access control mech- 
anism. These program-specific identifiers can be re- 
garded as names for the programs and are obtained by 
applying a hash function to the programs. The output, 
the program-specific identifier, also called hash value, 
is a substantially unique value for a specific program that 
might be stored, cached, or derived on-the-fty. In gen- 
eral, the names are provided by the trusted computing 
base or in more detail by an operating system. The cryp- 
tographic function fulfills at least the following criteria. 
The time to create such a specific identifier is substan- 
tially shorter than the time to reconstruct the program or 
part thereof out of the specific identifier. Moreover, the 
time to find two identical specific identifiers is substan- 
tially longer than the time to create one specific identifi- 
er. 

[0023] The mechanism runs as follows. A message- 
originator program sends a message including its de- 
rived name to a message-receiver program. The name 
is provided by the operating system and might be added 
to the message during sending or transferring. After re- 



ceiving the message, the name is verified whether it is 
known to the message-receiver program and/or the 
trusted computing base. By doing so, the message that 
may include a special request can be accepted or re- 

5 Jected depending on the verification. For a response to 
the message, the message-receiver program converts 
to a so-called response-message-originator program, i. 
e. the message-receiver program becomes a message- 
originator program, and sends a message-response 

10 with its specific name. 

[0024] Under a program is understood any kind of 
code or software which is able to run on a computer, 
such as application programs, Java-based programs, or 
virtual machines. 

is [0025] The present mechanism shows several advan- 
tages, such as it is not spoof able and is easily imple- 
mented. The work of a system administrator becomes 
redundant, since the names are created automatically 
by the trusted computing base. In general, the trustwor- 

20 thiness of computers can be increased dramatically and 
make them to safe and reliable devices, since several 
domains or applications can run one the same computer 
without being attackable by insecure programs. 
[0026] By using the mechanism, uncontrolled and po- 

25 tentially insecure programs, such as suspected and at- 
tacking programs, cannot take control over the compu- 
ter or interfere sensitive programs and applications. 
[0027] On the one hand, if a program-specific identi- 
fier, i.e. a program-specific name, is known to the mes- 

30 sage-receiver program and a response-message is sent 
comprising an acceptation or acknowledgment and a re- 
sponse-program-specific identifier that, on the other 
hand, is known to the message-originator program, then 
the advantage occurs that both programs can trust each 

35 other, whereby the message-receiver program is then 
willing to inter-operate with the message-originator pro- 
gram. A trusted communication between both program 
can be set up easily. 

[0028] Such a mentioned program-specific identifier 
40 is derivabte by applying a first hash function to the mes- 
sage-originator program and a response-program-spe- 
cific identifier is derivable by applying a second hash 
function to the message-receiver program. This proves 
advantageous because, in general, various hash func- 
45 tions can be applied to create a program-specific iden- 
tifier and thus the mechanism is not restricted to a spe- 
cial type of hash function. The only assumption is that 
the program-specific identifier should be known to the 
message-receiver program in order to set up communi- 
so cation. 

[0029] Nevertheless; the applied hash functions can 
be also identical, whereby a one-way-hash function, 
such as MD5 or SH A-1 is applicable. Such hash function 
are well known, work reliable, and can be processed, i. 
55 e. applied to a program in the millisecond time scale, 
without any remarkable effect to the user or the comput- 
ing time in general. 

[0030] A hash-function generator should be imple- 
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merited into the trusted computing base, such that the 
program-specific identifiers are derived and provided by 
this trusted computing base automatically. Based on the 
underlying security policy, the trusted computing base 
cannot be circumvented or undermined by an attacker. 
[0031 J It is advantageous if the program-specific iden- 
tifier and/or the message is signed by use of a private 
cryptographic key. By doing so, mutual trust between 
different programs can be established and set up easily. 
Moreover, arbitrarily trust relationships can be created, 
whereby it is particularly advantageous that the user has 
nothing to configure. 

[0032] It is also advantageous if an additional pro- 
gram-specific identifier which is signed by the private 
cryptographic key is sent within the message, because 
the message -receiver program becomes securely man- 
ageable by developers whereby additional trusted pro- 
grams can be Installed and therewith trusted domains 
or applications can be set up easily. In other words, dif- 
ferent programs which come from the same developer 
trust each other and can create mutual trust relation- 
ships. 

[0033] The message-receiver program and/or the 
trusted computing base might have a public crypto- 
graphic key with which the response can be singed. This 
implies that if the message-originator program, that 
means the requesting program, has been written cor- 
rectly, the message-receiver program and/or the trusted 
computing base will generate signatures only for docu- 
ments that have been authorized by the user. 
[0034] If program-specific identifiers are pre-stored in 
a list or a database, than a fast access to this identifiers 
and therefore a fast verification can be provided. It 
shows also advantageous if trusted program-specific 
identifiers are delivered or installed within the trusted 
computing base or when the computer is initialized for 
the very first time. 

[0035] In the case that the program-specific identifier 
is not known to the message-receiver program and/or 
the trusted computing base, the message or request is 
rejected, for example be returning a zero to the mes- 
sage-originator program . This implies that the message- 
originator program is not a trusted one and might be sus- 
pect or even dangerous. For such programs a special 
domain can be created. But again, the positive point is 
that such programs can not interfere others, that means, 
for example, trusted programs, relevant documents, or 
private records on the computer. 

DESCRIPTION OF THE DRAWINGS 

[0036] The invention is described in detail below with 
reference to the accompanying schematic drawings, 
wherein: 

FIG. 1 shows a block diagram of a computer sys- 
tem; 

FIG. 2 shows a schematic illustration of an ex- 
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change of messages according to the 
present invention; 
FIG. 3 shows a schematic illustration of a purchase 
scenario using a key; 
5 FIG. 4a shows a schematic illustration of a file sys- 
tem object with access control using a hash; 
FIG. 4b shows the file system object of FIG. 4a for 
dynamic setup using digital signatures; and 
FIG. 5 shows a schematic illustration of an embod- 
10 iment using a helper application to set up 

mutual trust relationships. 

[0037] All the figures are for the sake of clarity not 
shown in real dimensions, nor are the relations between 
15 the dimensions shown in a realistic scale. 

DESCRIPTION OF PREFERRED EMBODIMENTS 

[0038] With general reference to the figures and with 
special reference to Fig. 1 the essential features of an 
access control mechanism for computers using crypto- 
graphic functions is described in more detail below. At 
first, some general points are addressed. 



[0039] A hash function is a computationally efficient 
function mapping binary strings of arbitrary length to bi- 
nary strings of some fixed length. 

30 

One-way hash function 

[00401 A one-way hash function is a function which 
takes a variable-length message and produces a fixed- 
35 length hash or value. Thus: h = H(M), with Hthe one- 
way hash function, Afthe message and ft the hash value 
for message M. Given the hash h it is computationally 
infeasible to find a message Mwith that hash; in fact 
one can't determine any usable information about a 
40 message M with that hash. For some one-way hash 
functions it is also computationally infeasible to deter- 
mine two messages which produce the same hash. 
Moreover, a one-way hash function can be private or 
public, just like an encryption function. MD5, SHA-1 , and 
^5 Snefru are examples of public one-way hash functions. 
[0041 ] If such a one-way hash function is applied to a 
program E, which can be any program, than the output, 
the hash value h, is a substantially unique value, also 
referred to as program-specific identifier. This program- 
so specific identifier can also be seen as a name that is 
given to the specific program E. In other words, the pro- 
gram £, that can be viewed as a byte stream E = {b 0 , 
b v b 2 , ...}, can be associated with its substantially 
unique name H(E). When the program £is run, it run 
55 with the label H(E). Persistent data created by the pro- 
gram E is accessible only to the program E and also 
bears the name H(E). 

[0042] Using for example the above mentioned one- 
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way hash function SHA-1 , the probability to find two 
identical program-specific identifiers is approximately 1 
to 2 80 , and the probability to find to a given program an- 
other program with the same program-specific identifier 
is approximately 1 to 2 160 . 

Trusted computing base (TCB) 

[0043] Undertrusted computing base, also abbreviat- 
ed as TCB, is understood the totality of protection mech- 
anisms within a computer system, including hardware, 
firmware, and software, the combination of which is re- 
sponsible for enforcing a security policy. An operating 
system being part of the trusted computing base. The 
security policy requests that the trusted computing base 
cannot be circumvented or undermined, i.e. it is secure 
against attacks. 

[0044] The present access control mechanism can be 
used in general in computers and computer systems. 
When referring to a computer, any kind of device is 
meant that can be a member of a local network. Exam- 
ples of devices are: laptop computers, workpads, node- 
pads, personal digital assistants (PDAs), notebook 
computers and other wearable computers, desktop 
computers, computer terminals, networked computers, 
internet terminals and other computing systems, set-top 
boxes, cash registers, barcode scanners, point of sales 
terminals, kiosk systems, cellular phones, pagers, wrist 
watches, digital watches, badges, smartcards, and oth- 
er handheld and embedded devices. Other devices con- 
sidered include: headsets, Human Interface Device 
(HID) compliant peripherals, data and voice access 
points, cameras, printers, fax machines, keyboards, joy- 
sticks, kitchen appliances, tools, sensors such as 
smoke and/or fire detectors, and virtually any other dig- 
ital device. 

[0045] Other examples of wearable computers that 
can be used in connection with the present invention 
are, personal effects being equipped with computer-like 
hardware, such as a "smart waller computer, jewelry, 
or articles of clothing. In addition to a "smart waller com- 
puter, there are a number of other variations of the wear- 
able computers. A "belt" computer is such a variation 
which allows the user to surf, dictate, and edit docu- 
ments while they are moving around. Yet another exam- 
ple is a children's computer which is comparable to a 
personal digital assistant for grade-school children. The 
children's computer might hold assignments, perform 
calculations, and help kids manage their homework. It 
can interface with other children's computers to facilitate 
collaboration, and it can access a teacher's computer to 
download assignments or feedback. Any wearable or 
portable device, any office tool or equipment, hometool 
or equipment, system for use in vehicles, or systems for 
use in the public (vending machines, ticketing ma- 
chines, automated teller machines, etc.) might be used 
in the context of the present invention. 
[0046] In order to aid in the understanding of the 



present invention, Fig. 1 shows a high-level block dia- 
gram of a computer 2. 

[0047] The computer 2 includes hardware compo- 
nents 4 such as one or more central processing units 

5 (CPU) 6, a random access memory (RAM) 8, and an 
input/output (I/O) interface 1 0. The computer 2 also in- 
cludes an operating system 20. Various peripheral de- 
vices are connected to the computer 2, such as second- 
ary storage devices 12 (such as a hard drive), input de- 

10 vices 14 (such as keyboard, mouse, touch screen, a mi- 
crophone, or infrared- or RF receiver), display devices 
16 (such as a monitor or an LCD display), and output 
devices 18 (such as printers, or infrared- or RF trans- 
mitter). Also a smartcard device could be coupled to the 

15 input/output devices 14, 18. A plurality of programs 22, 
24, 26 are executed in the computer 2. The programs 
22, 24, 26 may be executed sequentially in the computer 
2, but preferably executed in parallel In the computer 
system 2. 

2Q [0048] The hardware components 4 and the operating 
system 20 form a trusted computing base TCB, which 
constitute the basis for a secure and trusted computing. 
Into the trusted computing base, a generator-module 21 
for creating program-specific Identifiers is implemented. 
25 This generator-module 21 is basically a cryptographic- 
function generator 21 that can be implemented in soft- 
ware as well as in hardware. Since the generation of a 
hash value by applying a hash function, preferably a 
one-way hash function as described above, is not time- 
so consuming for a processor, the cryptographic-function 
generator 21 might be implemented in the operating 
system 20 itself. Any cryptographic-function might be 
suitable that outputs a substantially unique value. 
[0049] The structure of the computer 2, as described 
35 with reference to Fig. 1 , is to be seen as the underlying 
device, that can be used in the following embodiments. 
[0050] Still referring to Fig. 2, which shows a high-lev- 
el schematic illustration of an exchange of messages. 
Some basics are explained in the following. A message- 
40 originator program D wants to communicate with anoth- 
er program, here a message-receiver program S. The 
message-receiver program S knows one or more pro- 
gram-specific identifiers. These identifiers could be pre- 
stored or cashed and might be also known to the oper- 
45 ating system 20. At first, the message-originator pro- 
gram D sends a request m within a message to the mes- 
sage-receiver program S. Thereby, the generator-mod- 
ule 21 as part of the operating system 20 derives a pro- 
gram-specific identifier H(D) from the message-origina- 
50 tor program D and adds this program-specific identifier 
H(D) to the message, as indicated by the arrow labeled 
w\ih H(D), m. 

[0051] In general, the operating system 20 adds to all 
requests sent by a message-originator program to a 
55 message-receiver program the respective program- 
specific identifier of the message-originator program 
which then can be verified or identified by the message- 
receiver program. 
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[0052] For simplification reasons, the generator-mod- 
ule 21 is not shown in Fig. 2. The program-specific iden- 
tifier H(D) can also be pre-stored from the message- 
originator program D. After receiving the message in- 
cluding the program-specific identifier H(D) and the re- 5 
quest m, the message-receiver program S tries to ex- 
tract the program-specific identifier H(D) and verifies it 
with its known identifiers. If the program-specific identi- 
fier H(D), is known to the message-receiver program S, 
whereby this is here indicated by H(D) in box S, the mes- * o 
sage-receiver program S would accept further commu- 
nication with the message-originator program D. For 
that, the message-receiver program S sends a re- 
sponse-message comprising a response n and its pro- 
gram-specific identifier H(S), also referred to as re- 15 
sponse-program-specific identifier H(S) f to the mes- 
sage-originator program D, as indicated by the arrow 
from box S to box D. The response-program-specific 
identifier H(S) is thereby also provided by the operating 
system 20. Since the message-originator program D 20 
and the message-receiver program S can be executed 
on different computers or systems which are connecta- 
ble via a network, each program D, S can have its trust- 
ed computing base that provides program specific iden- 
tifiers . A connection to the network is provided by means 25 
known in the art, such as wire, infrared, RF t et cetera. 
[0053] In the following, the various exemplary embod- 
iments of the invention are described. 
[0054] Fig. 3 shows a schematic illustration of a pur- 
chase scenario using a key. Based on the trusted com- 30 
puting base and therewith on the operating system 20 
run several programs or applications in compartments, 
that here is called browse B, display D and sign S. The 
underlying conception of this embodiment is that any- 
one should be able to ask for something. Since display 35 
D and sign S run in a secure compartment and thus are 
trustworthy whilst browse B is not, browse B or any other 
program can send a request to display D. 
[0055] For example, when a signature is needed, a 
document is passed to the secure compartments dis- <*o 
play D and sign S for display, authorization, and signa- 
ture generation. The security of the scheme is depend- 
ent only upon the sign S and display D compartment 
and its ability to display information to the user, and the 
sign compartment's ability to accept requests from dis- 
play D. Only sign S needs access to a signing key k, as 
indicated in box S. 

[0056] The display D compartment's ability to display 
data to a user has two primary assumptions: that the 
compartment can obtain a resource lock on the display so 
D and that the data itself have a single well defined 
meaning. The ability to lock the display D is useful to 
diminish the threat of Trojan Horses. The granting of ex- 
clusive locks on system resources allows malicious 
code to either soft or hard lock the system thereby stag- ss 
ing a denial of service attack. Assuming that ail system 
locks can be forced to be soft locks, this threat is not 
interesting. It is thus the case that the primary issue is 



that the system should be able to lock a sufficient 
number of resources. These resources include the dis- 
play, touch screen, various other I/O devices, memory 
pages, et cetera. 

[0057] Sign S should be able to protect and manage 
its key k and to ensure that a request to sign a document 
came from browse B. Protecting and managing these 
data means that they should only be accessible to other 
compartments though sign's external interfaces. This 
implies certain low level properties of the system: the 
system should not allow raw access to memory, the in- 
tegrity of messages (IPC) should be maintained, and ac- 
cess to system resources does not use the complete 
privileges. 

[0058] By using the above described scheme of gen- 
erating program-specific identifiers for each compart- 
ment, a naming system is provided so that there is a well 
defined difference between compartments. 
[0059] It is assumed that a user wants to select and 
purchase an item. The item can be selected using 
browse B, that is a browser, as that of WAP (Wireless 
Applications Protocol), running on a PDA (personal dig- 
ital assistant) that may bases on the computer as indi- 
cated with reference to Fig. 1 . A browser is an extremely 
sophisticated piece of software that acts upon complex 
data supplied by untrusted users. It is possible, howev- 
er, for the browser B to generate a request which is 
handed to display D and sign S for terms of payment 
authorization. For that, the browser B sends a request 
m to sign a document within a message to display D, 
whereby the operating system 20 attaches to the re- 
quest m the program^specific identifier H(B) of browser 
B. This is indicated by the arrow labeled with H(B), m 
[0060] Display D, that is compared to browse B as 
small piece of software, forwards the request m with its 
program-specific identifier H(D), as indicated by the ar- 
row labeled with H(D), m. The sign compartment, sign 
S, that might be a smartcard, verifies the received mes- 
sage with its known program-specific identifiers. When 
the program-specific identifier H(D) is known to sign S, 
whereby this is here indicated by H(D) in box S, the re- 
quest m is accepted. Moreover, if display D has been 
written correctly, sign S generates signatures only for 
documents that have been authorized by the user. 
[0061] A signature on the request m under the key k 
is denoted as k ~ 1 . Sign S signs the request m and sends 
it together with its program-specific identifier to display 
D. This is indicated by the arrow labeled with H(S), hr 1 
m. Further, display D passes the signed request with its 
program-specific identifier to browse B, as indicated by 
the arrow labeled with H(D), k' 1 m. 
[0062] Fig. 4a shows a schematic illustration of a file 
system object with access control using a hash. Natu- 
rally, there Is a need for different applications, hereafter 
also referred to as objects, to share data. Fig. 4a indi- 
cates persistent objects, namely object A, object F, and 
object G, whereby object A and object G are connected 
to object F, that is a trusted object. Moreover, object F 
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has an access control list 40 with entries for object A 
only. The object F receives two read requests /-fa/) and 
rfn]), both accompanied by the respective program- 
specific identifier H(A) and H(G). as it is indicated by the 
arrows labeled with HfflrfnJ and H(G),r(n 2 ) towards s 
object F, respectively. The first request rfnjcomes from 
object A, which appears in object F 's access control list 
40. This is granted, whereby d, is returned by object F 
as indicated by the arrow labeled with H(F), d t . The sec- 
ond request r(n 2 ) comes from object G, which does not to 
appear in object F 's access control list 40. Thus, the 
second request r(n^ is denied, whereby a null is re- 
turned as indicated by the arrow labeled with H(F),0. 
Different access control lists could be kept for read and 
write privileges. 15 
[0063] More complex objects F with rich method sets 
can use the same type of construction to implement de- 
sired access control policies in generality. 
[0064] While Fig. 4a illustrates a static setup which 
does not allow to update the collection of trusted objects, 20 
Fig. 4b shows, based on the configuration of Fig. 4a f a 
file system object for dynamic setup, 
[0065] The configuration of Fig . 4a can be updated us- 
ing digital signatures. Therefore, object F has a public 
key K. as indicated in box F. Object F and object G are 25 
based on a first operating system 42, whilst a helper ap- 
plication, also referred to as object C, bases on a second 
operating system 44 which are connected by a channel 
46 as it is known in the art. The first operating system 
42 runs at a user whereas the second operating system so 
44 runs at a developer or a trusted entity. Object C is 
used to deliver tc 1 H(G). whereby k 1 is a private key, to 
object F which verifies the validity of the signature and 
adds the program-specific identifier H(G) of the object 
G to its access control list 40. 35 
[0066] Access requests such as H(G),r(ni) from ob- 
ject G to object F will now be granted by object F, that 
returns H(F), d 1t as indicated by the respective arrows. 
[0067] The construction depends upon the fact that 
the bearer of a digital signature does not need to be *o 
trusted so long as the signature is valid. 
[0068] One can use this very fact to set up arbitrarily 
complicated trust relationships using a helper applica- 
tion. 

[0069] Fig. 5 shows a schematic illustration of an em- *s 
bodiment using a helper application, that here is object 
C again, to set up mutual trust (MT) relationship be- 
tween object A and object G. Both objects A, G have the 
public key k and their own specific access control list, 
as indicated below the objects A, G, respectively. Using so 
object C as the helper application, object C delivers k' 1 
H(G) with its program-specific identifier H(C) to object 
A, which verifies the validity of the signature and adds 
the program-specific identifier H(G) to its access control 
list. On the other hand, object C delivers lc 1 H(A) with 55 
its program-specific identifier H(C) to object G, which 
verifies the validity of the signature and adds the pro- 
gram-specific identifier WW to its access control list. For 



further communication, object A can contact directly ob- 
ject G and vice versa, because now they know and trust 
each other, as indicated by the doted line between box 
A and G. 

[0070] The scheme described with reference to Fig. 
5 is not the same as traditional code signing which re- 
quires an intractable hierarchy of keys, certificates, de- 
veloper registration, an so forth. The scheme does not 
use code signing to determine system privileges but is 
rather using signatures as credentials in a developer 
software coterie. 

[0071] An example of where this might be useful is if 
a bank has several payment schemes which wish to 
share a common key. The individual components can 
be updated independently. 

[0072] The following embodiment describes the de- 
sign of a payment system using digital signatures using 
the access control mechanism based on cryptographic 
functions. This system is designed to be used through 
WAP without depending upon the security of WAP itself. 
Several steps are indicated in the following. 

Global Setup 

[0073] The initial setup for a bank is not too intrusive, 
since the bank need not contact the creators of the de- 
vice, i.e. manufacturer of the PDA or computer 

1 . The bank generates a public key/private key pair 
to sign individual users keys. This key pair is denot- 
ed as mk/mk 1 . This could be the banks master key 
or some derivative thereof. 

2. The bank generates a public key/private key pair 
to identify membership in the banks suite of appli- 
cations. This key pair is denoted as ak/afc 1 . 

3. The bank writes a signing program S that com- 
prises the public keys mk and ak. 

4. Moreover, the bank writes a display program D t 
such as described with reference to Fig. 3. It ac- 
cepts as a simple description of that which is to be 
signed, e.g. payee, amount, date, and description. 
The display program Dthen locks the physical dis- 
play device and displays afterwards the necessary 
information to the user, if the user agrees, the dis- 
play program D releases the lock and the terms will 
be passed to a signing program S, such as men- 
tioned with reference to Fig. 3. 

5. The bank computes ka~ 1 H(D) and places this in 
a helper or registration program C, as shown with 
reference to Fig. 5. 

individual Setup 

[0074] It is assumed that the bank wishes to generate 
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and distribute keys for the user 

1. For each user U, the bank generates a key pair 
uk/ulc 1 and an application CU carrying the signed 
key pair mk ~ 1 (ukfulc 1 ). 

2. The bank provides to the user U the display pro- 
gram 0, the signing program S t the registration pro- 
gram C, and the application CU. Only the applica- 
tion CU depends on the user U and is the only com- 
ponent requiring secrecy. The bank may wish to 
split the secret in some way. 

3. Then, the user U installs the applications men- 
tioned in the step above and the system automati- 
cally sets up four new security domains correspond- 
ing to the respective program-specific Identifiers H 
(D), H(S), H(C), and H(CU). 

4. The user U executes application CU which sends 
to the signing program S a message including mk * 1 
{uk I uk -*). The signing program S verifies that ukf 
ulc 1 is a valid user key using the key mk. The appli- 
cation CUthon calls the registration program Cand 
deletes itself, because it has no more purposes. 
The registration program C sends to the signing 
program 5a message including kar 1 H(D). Next, the 
signing program S uses ka to verify whether the dis- 
play program D is a trusted application. Hence, the 
signing program S trusts the display program D. 

[0075] When an application or program, as the WAP 
browser wishes to generate a signature, it passes the 
text or document to the display program D for display 
and approval If the user U approves the request is 
passed on to the signing program S which then sign it. 
The signing program S knows that the request reflects 
the users desires because it comes from the trusted dis- 
play program D. The signature is eventually returned to 
the initial application. 

[0076] If the bank wishes to generate a new applica- 
tion N, e.g. for home banking, trusted by the signing pro- 
gram Sthen they only generate a helper application C 
carrying ka ' 1 H(N). 

Smartcard 

[0077] If the bank wishes to use a smartcard to protect 
the private portion of the user's key pair, then the Indi- 
vidual Setup can be varied as follows. 

1 . For each user the bank generates a key pair 
ukl ulc 1 and put it on the smartcard. This key pair 
ukfulc 1 can be signed with the bank's master key 
m7r 1 (ukfulc 1 ). 

2. The bank provides to the user U s at least the dis- 
play program D and the registration program C. 



3. Then, the user U s installs the applications men- 
tioned in the step above and the system automati- 
cally sets up two new security domains correspond- 
ing to the respective program-specific identifiers H 

s (D) and H(C). 

4. The user U s executes the registration program C 
which sends the smartcard a message including 
ka' 1 H(D). The smartcard uses ka to verify that the 

10 display program D is a trusted application and 
henceforth trusts the display program D. 

[0078] When the display program D sends a request 
to the smartcard, the request is delivered along with the 
'5 program-specific identifier H(D) of the display program 
D. 

[0079] Any disclosed embodiment may be combined 
with one or several of the other embodiments shown 
and/or described. This is also possible for one or more 

20 features of the embodiments. 

[0080] The present invention can be realized in hard- 
ware, software, or a combination of hardware and soft- 
ware. Any kind of computer system - or other apparatus 
adapted for carrying out the methods described herein 

25 - is suited. A typical combination of hardware and soft- 
ware could be a general purpose computer system with 
a computer program that, when being loaded and exe- 
cuted, controls the computer system such that it carries 
out the methods described herein. The present inven- 

30 tion can also be embedded in acomputerprogram prod- 
uct, which comprises all the features enabling the im- 
plementation of the methods described herein, and 
which - when loaded in a computer system - is able to 
carry out these methods. 

35 [0081] Computer program means or computer pro- 
gram in the present context mean any expression , in any 
language, code or notation, of a set of instructions in- 
tended to cause a system having an information 
processing capability to perform a particular function ei- 

40 ther directly or after either or both of the following a) con- 
version to another language, code or notation; b) repro- 
duction in a different material form. 



45 Claims 

1. A method for verifying the identity of a message- 
originator program (D) by a message-receiver pro- 
gram (S), the method comprising the steps of: 

so 

receiving from said message-originator pro- 
gram (D) a message comprising a program- 
specific identifier (H(D)) t which has been pro- 
vided for said message-originator program (D) 
55 by means of a trusted computing base (TCB); 

and 

verifying whether said received program-spe- 
cific identifier (H(D)) is known to said message- 
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receiver program (S). 

2. A method for disclosing the identity of a message- 
originator program (D) to a message-receiver pro- 
gram (S), the method comprising: 

- sending from said message-originator program 
(D) to said message-receiver program (S) a 
message comprising a program-specific iden- 
tifier (H(D)), which has been provided for said 
message-originator program (D) by means of a 
trusted computing base (TCB), said program- 
specific identifier (H(D)) being verifiable at said 
message-receiver program (S) whether it is 
known to said message- receiver program (S). 

3. A method for verifying the identity of a message- 
originator program (D) by a message-receiver pro- 
gram (S), the method comprising the steps of: 

- providing a program-specific identifier (H(D)) 
for said message-originator program (D) by 
means of a trusted computing base (TCB): 
sending from said message-originator program 
(D) to said message-receiver program (S) a 
message comprising said program-specific 
identifier (H(D)); 

receiving at said message-receiver program 
(S) said message; and 

- verifying whether said received program-spe- 
cific identifier (H(D)) is known to said message- 
receiver program (S). 

4. Method according to one of claims 1 to 3, wherein 
the message-receiver program (S) afterwards be- 
comes a response-message-originator program 
and sends a response-message to the message- 
originator program (D) comprising: 

- a response-program-specific identifier (H(S)), 
which has been provided for said response- 
message-originator program by means of the 
trusted computing base (TCB); and 

• an acknowledgment if the program-specific 
identifier (H(D)) has been verified as being 
known. 

5. Method according to one of claims 1 to 3, wherein 
a substantially unique cryptographic identifier that 
is derived by applying a cryptographic function (H) 
to the message-originator program (D), preferably 
a hash function, and more preferably a one-way- 
hash function, such as MD5 or SHA-1 , is used as 
the program-specific identifier (H(D)). 

6. Method according to one of claims 1 to 3, further 
comprising the step of signing the program-specific 
identifier (H(D)) and/or the message by use of a pri- 



vate cryptographic key (ic 1 ) to establish trust be- 
tween different programs. 

7. Method according to claim 6, wherein the message 
5 further comprises an additional program-specific 
identifier (H(G)) that is signed by use of the private 
cryptographic key (Ic 1 ) to establish a membership 
of an additional program in a trust relationship. 

10 8. Method according to one of claims 1 to 3, wherein 
the message-receiver program (S) has a public 
cryptographic key (*). 

9. Method according to one of claims 1 to 3, wherein 
is the message-receiver program (S) and/or the trust- 
ed computing base (TCB) use(s) a list comprising 
pre-stored program-specific identifiers and wherein 
said message-receiver program (S) verifies wheth- 
er the program-specific identifier (H(D)) is identical 

20 to one of said pre-stored program-specific identifi- 
ers. 

10. Method according to one of claims 1 to 3, wherein 
the message-receiver program (S) sends a rejec- 
ts tion-message if the program-specific identifier (H 

(D)) is not verified as being known. 

11. Method according to one of claims 1 to 3, wherein 
the message-originator program (D) and the mes- 

30 sage-receiver program (S) are executed on differ- 
ent systems and are connectable via a network, 
each having its trusted computing base (TCB) for 
providing program-specific cryptographic identifi- 
ers. 

35 

12. A computer program comprising program code 
means for performing the steps of any one of the 
claims 1 to 11 when said program is run on a com- 
puter. 

40 

13. A computer program product comprising program 
code means stored on a computer readable medi- 
um for performing the method of any one of the 
claims 1 to 11 when said program product is run on 

45 a computer. 

1 4. An apparatus for verifying the identity of a message- 
originator program (D) by a message-receiver pro- 
gram (S) on a computer, the apparatus comprising: 

so 

computing means; 

a receiver-module for receiving from said mes- 
sage-originator program (D) a message com- 
prising a program-specific identifier (H(D)), 
55 which has been provided for said message- 

originator program (D) by means of a trusted 
computing base (TCB); and 
- a verifier-module that verifies whether said pro- 
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gram-specific identifier (H(D)) is known to said 
message-receiver program (S). 

1 5. An apparatus for disclosing the identity of a mes- 
sage-originator program (D) by a message-receiver s 
program (S) on a computer, the apparatus compris- 
ing: 

computing means; 
• a trusted computing base (TCB) comprising a to 
generator-module for creating a program-spe- 
cific identifier (H(D)); and 
a sender-module for sending from said mes- 
sage-originator program (D) a message com- 
prising said program-specific identifier (H(D)), ts 
said program-specific identifier (H(O)) being 
verifiable at said message-receiver program 
(S) whether it is known to said message-receiv- 
er program (S). 
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